Testpointanalysis: a method for test estimation

This document describes the test estimate preparation technique known as test point analysis (TPA). TPA can be used to objectively prepare an estimate for a system test or acceptance test. TPA covers only so-called black-box testing; an estimate for the test activities, which precede black-box testing (i.e. white-box testing), will already have been included in the estimate produced by function point analysis. So, while the function point analysis productivity factor covers the white-box testing, it does not cover system testing or acceptance testing. TPA can also be used if the test hour allowance has been predetermined. By performing a TPA, any risks involved can be clearly identified by comparing the objective TPA estimate with the predetermined number of test hours. With TPA, it is also possible to determine or calculate the relative importance of the various functions, with a view to using the available testing time as efficiently as possible. 1. Philosophy When formulating an estimate for a black-box test, three elements are relevant: the size of the information system to be tested, the test strategy (selection of system components and quality characteristics to be tested and the coverage of testing) and the level of productivity. The first two elements together determine the volume of testing work to be undertaken (expressed in test points). If the number of test points is multiplied by the productivity (the amount of time needed to perform a given volume of testing work) you get a test estimate in hours. The three elements, (size, test strategy and productivity) are considered in more detail below. 1.1 Size The first element to be considered is the size of the information system. For TPA purposes, the size of an information system is determined mainly by the number of function points [1] assigned to it. However, a number of additions or amendments need to be made, because certain factors which have little or no influence on the number of function points are pertinent to testing. The factors in question are the following: • Complexity; complexity relates to the number of conditions in a function. More conditions almost always means more test cases and therefore a greater volume of testing work. • Interfacing; the degree of interfacing of a function is determined by the number of data sets maintained by a function and the number of other functions, which make use of those data sets. Interfacing is relevant because these “other” functions will require testing if the maintenance function is modified. • Uniformity; it is important to consider the extent to which the structure of a function allows it to be tested using existing or slightly modified specifications, i.e. the extent to which the information system contains similarly structured functions. 1 TPA is registered trademark from IQUIP Published in Project Control for Software Quality, Kusters R., A Cowderoy, F. Heemstra and E. van Veenendaal (eds), Shaker Publishing BV, Maastricht, The Netherlands, 1999